home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970326-19970626 / 000011_news@columbia.edu _Fri Mar 28 14:41:39 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA16693
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 28 Mar 1997 14:41:38 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA08411
  7.     for kermit.misc@watsun; Fri, 28 Mar 1997 14:41:37 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.os.ms-windows.nt.misc,comp.protocols.kermit.misc
  11. Subject: Re: K95 Kermit flickers on Key Input in NT4.0
  12. Date: 28 Mar 1997 19:41:31 GMT
  13. Organization: Columbia University
  14. Lines: 83
  15. Message-ID: <5hh6tb$982$1@apakabar.cc.columbia.edu>
  16. References: <5hbo8d$lbi$1@news.impulse.net> <5hc84u$qum@watsun.cc.columbia.edu> <5hh2ug$e5p$1@news.impulse.net>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.os.ms-windows.nt.misc:185147 comp.protocols.kermit.misc:6826
  19.  
  20. More on this...
  21.  
  22. In article <5hh2ug$e5p$1@news.impulse.net>,
  23. Stephen Au <stephen@arktel.com> wrote:
  24. : >Frank da Cruz wrote:
  25. : >>In article <5hbo8d$lbi$1@news.impulse.net>,
  26. : >>Stephen Au <stephen@arktel.com> wrote:
  27. : >>: 
  28. : >>: I have been using K95 under WIN95 for sometime and it works OK (slow)
  29. : >>:
  30. : >>Slow compared to what?
  31. : 
  32. : Slow in couple respects, with serial connections @ 9600/19200 bps.
  33. : 
  34. : #1. Compared to real-life WYSE-60 terminals at 9600/19200 bps. 
  35. :
  36. Of course.  A terminal is a special-purpose device that does nothing but
  37. "terminal emulation" -- routing incoming bytes directly to the screen
  38. (possibly after interpreting some escape sequences using some (usually) very
  39. tight machine code in its PROM), and routing keystrokes directly to the serial
  40. port -- often using two separate dedicated processors.
  41.  
  42. : I grant that this "perception" of "slowness" is largely due to the pausing
  43. : between screen updates because I timed the output with a stop watch and the
  44. : result is similar.  But on keyboard input, there is just this perceptible
  45. : delay between a key is depressed and a character appearing on the screen.
  46. : And it slows down productivity.
  47. : 
  48. This does not happen to everybody.  Most people see an instantaneous response.
  49. When there *is* a delay, it is caused by Windows' scheduling of Kermit 95's
  50. threads.
  51.  
  52. : #2. Compared with other versions of Kermit, notably MSDOS and OS2/Warp 4.
  53. : 
  54. MS-DOS Kermit goes straight to the metal -- it's an operating system unto
  55. itself.  C-Kermit 5A(191) was not multithreaded, and so did not have to
  56. suffer through context switches.
  57.  
  58. : It takes longer for K95 to come up and exit...
  59. :
  60. Because Windows takes time to start Kermit's various threads.
  61.  
  62. : K95 feels sluggish/unresponsive on keyboard input.
  63. : 
  64. Again: to some, but not to most.
  65.  
  66. : #3. Compared with Qmodem.
  67. : It takes longer for K95 to come up and exit, K95 feels sluggish /
  68. : unresponsive on keyboard input.
  69. : 
  70. Unlike Qmodem, K95 runs in multiple threads.  Why?  Because it has multiple
  71. windows (even though in the current release you can only see one at at time);
  72. a thread per window, plus a dedicated blocking keyboard reading thread.  The
  73. multithreaded design makes K95 easy on your system, and allows us to maintain
  74. portability among Windows 95, Windows NT, and OS/2 in both a console version
  75. (which you have now) and a GUI version (coming up).  If we dropped support for
  76. the console version, a lot of people would be upset.
  77.  
  78. There are also other reasons for using multiple threads, many of which will
  79. not be evident to you till the GUI version comes out.  Well, here's one (which
  80. is already there to some extent): the ability to run the command processor and
  81. the terminal emulator simultaneously.  This is what allows INPUT statements
  82. (for example) to not have to worry about terminal ID or dimension query escape
  83. sequences.  All of this stuff works while your script is running.  Similarly
  84. for the command processor and the file transfer module -- e.g., it is possible
  85. right now for an INPUT command to sense an Kermit or Zmodem download and
  86. activate the file-transfer thread.  And so on.
  87.  
  88. Also...  K95's keyboard reader does a lot more than Qmodem's -- think of the
  89. multiple levels of key mapping (characters, strings, verbs, macros assigned to
  90. any key combinations at all without limit) AND character-set translation, the
  91. latter being important where English is not being used.
  92.  
  93. So yeah, there's a tradeoff -- functionality vs snappiness.  In each new
  94. release we do a lot of fine tuning to make K95 snappier and snappier, and this
  95. will continue.
  96.  
  97. But finally I have to emphasize again that the perceived sluggishness is not
  98. a universal phenomenon.  If we knew why it happens on some PCs but not others,
  99. we'd be the first to tell you.  Maybe we can take this off line via email to
  100. kermit-support@columbia.edu and do a more detailed analysis.
  101.  
  102. - Frank